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Abstract. Virtual integration techniques focus on building architectural 
models of systems that can be analyzed early in the design cycle to try 
to lower cost, reduce risk, and improve quality of complex embedded 
systems. Given appropriate architectural descriptions, assume/guarantee 
contracts, and compositional reasoning rules, these techniques can be 
used to prove important safety properties about the architecture prior 
to system construction. For these proofs to be meaningful, each leaf-level 
component contract must be realizable ; i.e., it is possible to construct a 
component such that for any input allowed by the contract assumptions, 
there is some output value that the component can produce that satisfies 
the contract guarantees. 

We have recently proposed (in [L]) a contract-based realizability check¬ 
ing algorithm for assume/guarantee contracts over infinite theories sup¬ 
ported by SMT solvers such as linear integer/real arithmetic and uninter¬ 
preted functions. In that work, we used an SMT solver and an algorithm 
similar to k-induction to establish the realizability of a contract, and 
justified our approach via a hand proof. Given the central importance 
of realizability to our virtual integration approach, we wanted additional 
confidence that our approach was sound. This paper describes a complete 
formalization of the approach in the Coq proof and specification lan¬ 
guage. During formalization, we found several small mistakes and miss¬ 
ing assumptions in our reasoning. Although these did not compromise 
the correctness of the algorithm used in the checking tools, they point to 
the value of machine-checked formalization. In addition, we believe this 
is the first machine-checked formalization for a realizability algorithm. 


1 Introduction 

An ongoing effort at Rockwell Collins and The University of Minnesota has ex¬ 
plored algorithms and tools for compositional proofs of correctness. The idea is to 
support hierarchical design and analysis of complex system architectures and co¬ 
evolution of requirements and architectures at multiple levels of abstraction [2]. 
We have created the AGREE reasoning framework [3] to support compositional 


assume/guarantee contract reasoning over system architectural models written 
in AADL. 

The soundness of the compositional argument requires that each leaf-level 
component contract is realizable ; i.e., it is possible to construct a component such 
that for any input allowed by the contract assumptions, there is some output 
value that the component can produce that satisfies the contract guarantees. 
Unfortunately, without engineering support it is all too easy to write contracts 
of leaf-level components that can’t be realized. When applying our tools in both 
industrial and classroom settings, this issue has led to incorrect compositional 
“proofs” of systems; in fact the goal of producing a compositional proof can 
lead to engineers modifying component-level requirements such that they are 
no longer possible to implement. In order to make our approach reasonable for 
practicing engineers, tool support must be provided for checking realizability. 

The notion of realizability has been well-studied for many years [4, 5,6,7,8, 9], 
both for component synthesis and checking correctness of propositional temporal 
logic requirements. Checking realizability for contracts involving theories, on 
the other hand, is still an open problem. In recent work [1], we described a 
new approach for checking realizability of contracts as a Satisfiability Modulo 
Theories (SMT) problem and demonstrated its usefulness on several examples. 
Our approach is similar to k-induction [10] over quantified formulas. In that 
work, we provided hand-proofs for several aspects of two algorithms related to 
the soundness of the approach with respect to both proofs and counterexamples. 

Unfortunately, hand proofs of complex systems often contain errors. Given 
the criticality of realizability checking to our tool chain and the soundness of our 
computational proofs, we would like a higher level of assurance than hand proofs 
can provide. In this paper, we provide a formalization of machine-checked proofs 
of correctness that ensure that the proposed realizability algorithms will perform 
as expected, using the Coq proof assistant. 3 The facilities in Coq, notably mixed 
use of induction and co-induction, make the construction of the proofs relatively 
straightforward. This approach illustrates how interactive theorem proving and 
SMT solving can be used together in a profitable way. Interactive theorem prov¬ 
ing is used for describing the soundness of the checking algorithm (described in 
this paper). The algorithm is then implemented using a SMT solver, which can 
automatically solve complex verification instances. 

The main contribution of this paper is, therefore, the first machine-checked 
formalization (to our knowledge) of a realizability checking algorithm. This is 
an important problem for both compositional verification involving virtual inte¬ 
gration and component synthesis. In addition, the formalization process exposed 
errors regarding our initial definitions, including necessary assumptions to one 
of the main theorems to be proved and an error in the definition of realizabil¬ 
ity itself. While these errors did not ultimately impact the correctness of the 
algorithm, they underscore the importance of machine-checked proof. 


The Coq file is available at https://github.com/andrewkatis/Coq/blob/ 
master/realizability/Realizability.v 
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In Section 2 we provide information on the Coq proof assistant. Section 3 con¬ 
tains the necessary informal background towards understanding our realizability 
checking approach. Sections 4.1 and 4.2 describe the definitions and theorems 
that were used both for defining realizability and the algorithms. In Section 5 
we provide details on the algorithm’s implementation. Finally, in Section 6 we 
discuss our experience from the process of defining realizability and the vari¬ 
ous changes that were made along the way, and we report our conclusions in 
Section 7. 

2 The Coq Proof Assistant 

Coq 4 is an interactive tool used to formalize mathematical expressions and al¬ 
gorithms, and prove theorems regarding their correctness and functionality [11]. 
The tool was a result of the work on the calculus of constructions [12]. Its 
uses in the context of computer science vary, such as being a tool to represent 
the structure of a programming language and its characteristics, as well as to 
prove the correctness of underlying procedures in compilers. Compared to other 
mainstream interactive theorem provers, Coq is a tool that provides support on 
several aspects, such as the use of dependent types, as opposed to the Isabelle 
theorem prover [13], and proof by reflection, which is not supported by the PVS 
proof assistant [1 ]. A particularly essential feature is the tool’s support for in¬ 
ductive and coinductive definitions. Definitions using the Inductive type in Coq 
represent a least fixpoint of the corresponding type and are always accompanied 
by an induction principle, which is implicitly used to progress through a proof 
by applying induction on the definition. Coinductive definitions, on the other 
hand, represent a greatest fixpoint to their type. They describe a set contain¬ 
ing every finite or infinite instance of that type, and their proofs are essentially 
infinite processes, built in a one-step fashion and requiring the existence of a 
guard condition that needs to hold for them to remain well-formed. Coinductive 
definitions allow a natural expression of infinite traces, which are central to our 
formalization of realizability, and are tedious to prove with hand-written proofs. 


3 Realizability Checking 

In [1] we presented our approach to the problem of realizability checking, intro¬ 
ducing an algorithm involving the use of theories, a concept that, to the best of 
our knowledge, has yet to be examined. The realizability checks are defined over 
assume-guarantee contracts. Informally, assumptions describe the expectations 
of the component on its environment, usually in terms of component inputs. The 
guarantees describe the properties that will hold with respect to component out¬ 
puts given that the assumptions are met. A contract holds on an infinite trace if 
either the assumption is violated or the guarantee holds throughout the trace. 

The Coq Proof Assistant is available at https : //coq. inria . fr/ 
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To illustrate, consider a system with a single integer input in and output out 
and a contract consisting of no assumptions and two guarantees: out = 2 *in and 
out > 0. This contract is not realizable. At issue is the behavior of the system if 
in < 0. In this case, the output of the system must both be positive and equal to 
2 * in, which is not possible. While this example is trivial, it can be very difficult 
to determine whether a contract involving dozens or hundreds of assumptions 
and guarantees is realizable. In [1], we describe two large-scale compositional 
reasoning examples (one medical device and one flight control system) that con¬ 
tained unrealizable leaf-level contracts that were previously unknown that were 
detected by our tools. 

Informally, a realizable contract is one for which there exists a transition 
system that correctly and completely implements the contract. By “correctly” 
we mean that the transition system always produces outputs that satisfy the 
guarantees as long as the assumptions have always been met, and by “completely” 
we mean that the transition system never deadlocks on an input, so long as the 
assumptions have always been met. We will make these definitions precise in the 
next section. 

This definition, while providing the proper theoretical basis for realizability, 
is not actually useful for constructing our checking algorithm. At issue is that our 
current algorithm provides no way to construct this ‘witness’ transition system 
(doing so would solve the general problem of program synthesis over contracts 
with theories, which we are currently researching). We therefore propose an 
alternative definition, according to which a contract is realizable if there exists a 
viable path consisting of viable states. A viable state is one where, for any inputs 
that satisfy the assumptions, there are outputs that satisfy the guarantees and 
lead to another viable state. This alternative definition requires that the contract 
be able to start in a viable state. 

To derive checking algorithms from first principles, we first demonstrate that 
the two definitions (transition systems and viability) are equivalent. We can then 
use the viable definition as the basis of an algorithm for realizability checking. 
This algorithm consists of a base check , which ensures that there exists a finitely 
viable state for paths of length at least n, and an extend check to show that all 
the valid paths can be further extended in response to any input. Unfortunately, 
the complexity of the base check does not allow for an SMT solver to handle it 
efficiently. Because of this, we propose a simplified version of the algorithm in¬ 
cluding a base check that ensures the extendability of every valid path consisting 
of viable states. This check is only guaranteed sound with regard to ’realizable’ 
results, that is, it may generate “false positives” in which the tool declares a con¬ 
tract unrealizable when in fact it can be realized. In early experiments, however, 
the tool results have been accurate. 

4 Formalization in Coq 

In the next two subsections, we will describe the formalization and proofs of 
these ideas in Coq. Section 4.1 will describe the definitions of realizability, while 


Section 4.2 will describe the algorithms for realizability checking and their proofs 
of adequacy with respect to the definitions. To provide a graphical overview of the 
proof process, Figure 1 describes the connections between the various definitions, 
lemmas, and theorems in our work. 
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4.1 Definitions 

The types state and inputs are used to represent a state, and a given set of 
inputs. We use Coq’s Prop definition to describe the logical propositions regard¬ 
ing the component’s transition system through a set I of initial states and 
the transition relation T between two states and a set of inputs. Finally, the 
contract is defined by its assumption and guarantee , with the latter being im¬ 
plicitly referenced by a pair of initial and transitional guarantees ( iguarantee 
and tguarantee). The corresponding definitions in Coq are shown below. Note 
that we do not expect that a contract would be defined over all variables in 
the transition system - rather its outputs - but we do not make any distinction 
between internal state variables and outputs in the formalism. This way, we can 
use state variables to, in some cases, simplify statements of guarantees. 

■ Inductive inputs : Type := 
input : id —> nat. —> inputs. 

m Inductive state : Type := 
st : id —» nat —► state. 

m Definition initial := state —> Prop. 






































■ Definition transition := state —> inputs —> state -A Prop. 

■ Definition iguarantee := state -A Prop. 

■ Definition tguarantee := state —a inputs —> state —> Prop. 

■ Definition assumption := state —» inputs —> Prop. 

A state s is reachable with respect to the given assumptions if there exists 
a path from an initial state to s, while each transition in the path is satisfying 
the assumptions. Given a contract (A,(Gi,Gt)), a transition system (I, T) is 
its realization if the following four conditions hold: 

1. Vs. I{s) =» G/(s) 

2. Vs, i, s'. reachableA^s ) A A(s, i) A T(s, i, s') =>■ Gt(s, i, s') 

3. 3s. /(s) 

4. Vs, A reachableA(s) A A(s, *) => 3s'. T(s, i, s') 

Finally, we define that a given contract is realizable, if the existence of a 
transition system, which is a realization of the contract, is proved. The formalized 
definitions in Coq for the reachable state, the realization of a contract and 
whether it is realizable follow. 

■ Inductive reachable (s : state) (I : initial) (T : transition) (A : assump¬ 
tion) : Prop := 

rch : 

((/ s) V 

((3 (s’ : state) (inp : inputs), 

(reachable s’ I T A) A (A s’ inp) A (T s’ inp s))) —> 
reachable si T A). 

m Inductive realization (I : initial) (T : transition) (A : assumption) (Gi : 
iguarantee) (Gt '■ tguarantee) : Prop := 
real : ((V (s : state), (I s) -A (G/ s)) A 
(V (s s’ : state) (inp : inputs), 

((reachable si T A) A (A s inp) A (T s inp s’)) —A Gt s inp s’) A 
(3 (s : state), Is) A 

(V (s : state) (inp : inputs), (reachable si T A A (A s inp)) —> 

(3 (s’ : state), T s inp s’))) —>■ 
realization I T A Gi Gt- 

m Inductive realizable-contract (A : assumption) (Gi : iguarantee) (Gt '■ 
tguarantee) : Prop := 

rc : (3 (I : initial) (T : transition), realization I T A Gj Gt) -a 
realizable-contract A Gi Gt- 

While the definitions of realization and realizable-contract are quite straight¬ 
forward, they cannot be used directly to construct an actual realizability check¬ 
ing algorithm. Therefore, we proposed the notion of a state being viable with 



respect to a contract, meaning that the transition system continues to be a re¬ 
alization of the contract, while we are at such a state. In other words, a state 
is viable (viable(s)) if the transitional guarantee Gt infinitely holds, given valid 
inputs. Using the definition of viable, a contract is realizable if and only if 
3s. G/(s) A viable(s). 

m Colnductive viable ( s : state) (A : assumption) (G/ : iguarantee) (Gt- 
tguarantee) : Prop := 
vbl : (V (inp : inputs), (A s inp) —> 

(3 (s’ : state), Gt s inp s’ A viable s’ A G/ Gt)) —► 
viable s A Gi Gt- 

m Inductive realizable (A : assumption) (Gi : iguarantee) (Gt '■ tguarantee) 

: Prop := 

rl : (3 (s : state), Gj s A viable s A Gi Gt) —> realizable A Gi Gt- 

Having a more useful definition for realizability, we need to prove the equiv¬ 
alence between the definitions of realizable-contract and realizable. The Coq 
definition of the theorem was split into two separate theorems, each for one of 
the two directions of the proof. Towards the two proofs, the auxiliary lemma 
that, given a realization, Vs. reachableA(s) => viable(s) is necessary. 

■ Lemma reachable-viable : V (s : state) (I : initial) (T : transition) (A : 
assumption) (Gi : iguarantee) (Gt '■ tguarantee), 

realization I T A Gi Gt -a reachable s I T A —» viable s A Gi Gt- 

The informal proof of the lemma relies initially on the unrolling of the viable 
definition, for a specific state s. Thus, we are left to prove that there exists 
another state s' that we can traverse into, in addition to being viable. The 
former can be proved directly from the conditions 2 and 4 of the definition of 
realization. For the latter, by the definition of viable on s' we need to show 
that s' is reachable. Given the definition of reachable though, we just need to 
prove that there exists another reachable state from which we can reach s', in 
one step. But we already know that s is such a state, and thus the lemma holds. 

■ Theorem realizable-contract-implies-realizable (I : initial) (T : transition) 

: V (A : assumption) (Gi : iguarantee) (Gt '■ tguarantee), 

realizable-contract A Gi Gt —> realizable A Gj Gt- 

m Theorem realizable-implies-realizable-contract (I : initial) (T : transition) 

: V (A : assumption) (Gj : iguarantee) (Gt '■ tguarantee), 

realizable A Gj Gt realizable-contract A G/ Gt- 

The first part of the theorem requires us to prove that there exists a viable 
state s for which the initial guarantee holds. Considering that we have a contract 
that is realizable under the realizable-contract definition, we have a transition 
system that is a realization of the contract, and thus from the third condition 
of the realization definition, there exists an initial state s' for which, using the 



first condition, the initial guarantee holds. Thus, we are left to prove that s' is 
viable. But, by proving that s' is reachable, we can use the reachable-viable 
lemma to show that s' is indeed viable. 

The second direction requires a bit more effort. Assuming that we have a vi¬ 
able state So with Gj(so) being true, we define I(s) = (s = Sq) an d T(s, inp, s') = 
Gt{s, inp , s') Aviable(s'). Initially, we need to prove the reachable-viable lemma 
in this context, with the additional assumption that another viable state already 
exists (so in this case). Having done so, we need to prove that there exists a transi¬ 
tion system that is a realization of the given contract. Given the transition system 
that we defined earlier, we need to show that each of the four conditions hold. 
Since I(s) = (s = so) and Gj(so) hold, the proof for the first condition is trivial. 
Using the assumption that T(s,inp , s') = Gr{s,inp , s') A viable(s'), we can also 
trivially prove the second condition, while the third condition is simply proved 
by reflexivity on the state s o- Finally, for the fourth condition we need to prove 
that Vs, inp. reachableA(s) A A(s, inp) => 3s'. Gt(s, inp , s') A viable(s'). By ap¬ 
plying the reachable-viable lemma on the reachable state s in the assumptions, 
we show that s is also viable, if s o is viable, which is what we assumed in the first 
place. Thus, coming back into what we need to prove, and unrolling the defini¬ 
tion of viable on s, we have that Vinp. A(s, inp) =>■ 3s'. Gt(s, inp , s') A viable(s') 
which completes the proof. 


4.2 Algorithms 

In this section we provide a description of the formalization and proof of sound¬ 
ness of our realizability checking algorithms. Initially, we define an under-approximation 
of the definition of viability, for the finite case. Thus, a state is finitely-viable 
for n steps (viable n (s)) , if the transitional guarantee Gt holds for at least n 
steps, given valid inputs. 

■ Inductive finitely-viable : nat -A state -A assumption -A tguarantee -A 
Prop := 

| fvnil : V s A Gt, finitely-viable O s A Gt 
| fv :\/ n s A Gt, finitely-viable n s A Gt —> 

(V (inp : inputs), A s inp -A (3 s’, Gt s inp s’)) —> 
finitely-viable (S n) s A Gt- 

In addition to the f initely-viable definition, an under-approximation of vi¬ 
ability is also used, called one-step extension. Therefore, a valid path leading to 
a state s is extendable after n steps, if any path from s, of length at least n, can 
be further extended given a valid input. 

■ Inductive extendable : nat -A state -A assumption -A tguarantee -A Prop 

| exnil : V (s : state) (A : assumption) (Gt ■ tguarantee), 

(V (inp : inputs), A s inp —► 3 (s’ : state), Gt s inp s’) > 

extendable O s A Gt 



| ex : V n s A Gt, 

(V inp s’, A s inp A Gt s inp s’ A extendable n s’ A Gt) —> 
extendable (S n) s A Gt- 


An Exact Algorithm for Realizability Checking The algorithm that we 
propose for realizability checking consists of two checks. The BaseCheck(n) 
procedure ensures that 3s. G/(s) A viable n (s), while ExtendCheck(n) makes 
sure that the given state from BaseCheck is extendable for any n. 

m Definition BaseCheck (n : nat) ( A : assumption ) (G/ : iguarantee) (Gt 
: tguarantee) := 

3 (s : state), (G/ s A finitely-Viable n s A Gt)- 

Definition ExtendCheck (n : nat) (A : assumption) (Gt '■ tguarantee) := 
V s A Gt, extendable n s A Gt- 

Using the BaseCheck(n) and ExtendCheck(n), the algorithm determines 
the realizability of the given contract, using the following procedure, 
for n = 0 to oo do 

if not BaseCheck(n) then 
return “unrealizable” 
else if ExtendCheck(n) then 
return “realizable” 
end if 
end for 

Using the definitions of BaseCheck and ExtendCheck, we proved the algo¬ 
rithm’s soundness, both for the ’unrealizable’ and ’realizable’ case. The main 
idea behind the proof of soundness for the ’unrealizable’ result is to prove the 
contrapositive, that is, given a realizable contract, there exists a natural number 
x for which BaseCheck(x) holds. Unfolding the definition of BaseCheck(x), 
we need to show that 3s. G/(s) A viable x (s). Knowing that our assumption 
realizable-contract A Gj Gt is equivalent to the realizable definition, pro¬ 
vides us with a state s', for which Gj(s') A viable(s') holds. Here, we need 
an additional lemma, according to which Vs, n. viable(s) => viable n (s) (stated 
as viable-implies-finitely-viable below). Thus, using the lemma on viable(s') 
with n = x, we get that viable x (s'), thus completing the proof. 

■ Lemma viable-implies-finitely-viable : V s A Gi Gt n, 
viable s A Gi Gt —> finitely-viable n s A Gt- 

■ Theorem unrealizable-soundness : V (I : initial) (T : transition) (A : as¬ 
sumption) (Gi : iguarantee) (Gt • tguarantee), 

(3 n, -i BaseCheck n A Gi Gt) ^ realizable-contract A Gi Gt- 


For the soundness of the ’realizable’ result, we first need to prove two lemmas. 
Initially, extend-viableshift, shows the way that Extend n (s) can be used to 



shift viable n (s) forward. The proof for this lemma is done by using induction on 
n. The base case is proved trivially, by unfolding the definitions of extendable 
and f initely-viable in the assumptions. For the inductive case, we assume that 
the same state s is extendable and finitely viable for paths of length n + 1, and 
try to prove that there exists a finitely viable state s' for paths of length n + 1, 
to which we can traverse from s, with the contract guarantees still holding after 
the transition. By considering that s is extendable for paths of length n + 1, we 
can use it as that potentially existing state in the proof, requiring that we can 
transition from s to itself, with the transitional guarantees staying true, and s 
being finitely viable for paths of length n + 1. The former is true through the 
definition of extendable, while the second is an already given assumption by the 
inductive step. 

■ Lemma extend-viableshift : V (s : state ) (n : nat) (inp : inputs) (A : as¬ 
sumption) (Gi : iguarantee) ( Gt '■ tguarantee), 

(extendable n s A Gt A finitely-viable n s A Gt A A s inp) —> 

(3 s’, Gt s inp s’ A finitely-viable n s’ A Gt)- 

m Lemma fv-ex-implies-viable : V (s : state) (n : nat) (A : assumption) Gj 

G t , 

(finitely-viable n s A Gt A ExtendCheck n A Gt) —> viable s A Gi Gt- 

■ Theorem realizable-soundness : V (I : initial) (T : transition) A Gi Gt, 

(3 n, (BaseCheck n A Gi Gt A ExtendCheck n A Gt)) —> 
realizable-contract A Gj Gt- 

To prove the theorem, we try to prove the equivalent for the realizable 
definition instead. The existence of a state for which the initial guarantees 
hold is derived from the assumption that BaseCheck holds for a finitely vi¬ 
able state, while the proof that the same state is also viable comes from the 
use of the fv-ex-implies-viable lemma, which is proved through the use of 
extend-viableshift. 


An Approximate Algorithm for Realizability Checking Following the 
definition of our approach, we noticed the problematic nature of BaseCheck(n) 
having 2 n quantifier alternations, which cannot be handled efficiently by an 
SMT solver. To that end, we proposed a simplified version of the BaseCheck(n) 
procedure, called BaseCheck' (n), stated as BaseCheck simple below. 

■ Definition BaseChecksimple (n : nat) (A : assumption) (Gj : iguaran¬ 
tee) (Gt '■ tguarantee) := V s, (Gi s) —> extendable n s A Gt- 

m Lemma finitely-viable-plus-one : V s n A (gi : iguarantee) (Gt '■ tguarantee) 
(inp : inputs), 

(extendable n s A Gt A finitely-viable n s A Gt) —> 
finitely-viable (S n) s A Gt- 



■ Theorem BaseCheck-Soundness : V n A ( Gj : iguarantee) ( Gt '■ tguarantee ) 
(i : inputs), 

((3 s, Gi s) A (V k, ( k<n ) —> BaseChecksimple k A Gj Gt)) —t 
BaseCheck n A Gi Gt- 

The simplified BaseCheck' (n), while being an easier instance for an SMT 
solver, is not sound for the ’unrealizable’ case, falsely reporting some realizable 
contracts to not be so. Nevertheless, we proved the modified algorithm’s sound¬ 
ness for the ’realizable’ result, with the use of an auxiliary lemma. 

The lemma, finitely-viable-plus-one simply refers to the fact that an ex¬ 
tendable and finitely viable state s, for a given number of steps n, is also finitely 
viable for n + 1 steps. The proof is done by induction on n. The base case is 
trivially proved, by the definition of f initely-viable, and the assumption that 
s is extendable. For the inductive case, we use the inductive hypothesis, which 
leaves us to prove the assumptions on a specific state s. The extendability is 
trivially shown since we already know that s is extendable for paths of length 
n + 1, with the same idea being applied to prove that s is finitely viable for n. 

Finally, the proof of soundness for the ’realizable’ result of the BaseCheck' (n) 
procedure is done by using induction on n. The base case is trivially true, using 
the fact that all paths of zero length are finitely viable. The inductive step then 
requires us to prove that BaseCheck(n + 1) holds. In order to do so, we need 
to construct the inductive hypothesis’ assumption, as a separate assumption to 
the theorem’s scope. By applying the inductive hypothesis to the newly created 
assumption, we have that BaseCheckfn) holds. By unrolling the definition of 
BaseCheck(n) and applying the lemma / initely-viable-plus-one on the ex¬ 
tracted state, say x, we finally prove that x is extendable through the definition 
of BaseCheck' (n), completing the proof at the same time. 

Figure 1 provides a simplified proof graph of all the necessary definitions 
and partially, for graph simplicity purposes, the way that they are used towards 
proving the lemmas and theorems stated in this paper. 


5 Implementation 

The algorithm is now an optional feature, namely JRealizability in JKind [15], 
a Java implementation of the KIND 2 model checker, 5 and supports models 
expressed using the Lustre language [16], which are a result of AGREE’s trans¬ 
lation process of contracts written in AADL. A typical process for checking 
models in the above environment starts from providing the corresponding Lus¬ 
tre program to JKind, which JRealizability uses to find a number n, n > 0, such 
that both BaseCheck'(n) and ExtendCheck(n) hold. Specifically, the model’s 
variables and contract are being translated in the SMT-LIB2 format, followed 
by the construction of each check’s corresponding query for the current value of 
n, in its negated form. The resulting SMT-LIB2 file is provided as input to the 

You can download the KIND model checker at http://kind2-mc.github.io/ 
kind2/ 
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Z3 SMT solver [17], which attempts to answer the given query. In the case that 
the negated formula is unsatisfiable, JRealizability returns a ’realizable’ result. 
On the other hand, a satisfiable query implies that the model is unrealizable. 
Consequently, the tool requests a model, i.e. an instance of the contract’s vari¬ 
ables that reflects Z3’s result, and proceeds to construct a counterexample that 
describes the exact cause of the contract’s unrealizability. Finally, in those cases 
where the quantified query is too difficult for Z3 to solve, an ’unknown’ result is 
reported, both by Z3 and JRealizability. 

The implementation was used in [1] to verify the correctness of contracts in 
terms of realizability in three different case studies. The performance was very 
good for the concrete results, with the tool exceeding its predefined timeout value 
for the ’unknown’ ones. False positive results (BaseCheck' (n)) were not found 
during this process, as every unrealizable contract was manually proved to be a 
result of conflicts in the provided assumptions or guarantees. A final remark is the 
fact that the most critical case studies already had an implementation that was 
supposed to work correctly. As such, the discovery of unrealizable contracts in 
these systems eventually required a total revision of the formalized requirements 
defined for each system, thus hindering the development process. 

6 Discussion 

While our work on realizability is based on simple definitions, formalizing them 
and refining the algorithms in Coq was non-trivial. Proving the lemmas and 
theorems using Coq helped us discover minor errors in our informal statements. 
For example, our proof of the one-way soundness theorem for the simplified 
BaseCheck in [I] lacks the necessary assumption that there exists a state for 
which the initial guarantees hold. Another example is that we forgot to include 
initial states in our definition of reachable states in the informal proof. The 
use of a mechanized theorem prover exposed some missing knowledge in the 
informal text, and helped us provide a more precise version of the theorem. 
Although these errors in the hand proofs did not lead to problems with our 
implementation, Coq improved both our theorems and proofs, and provided a 
very high level of assurance that our algorithm is correct. 

7 Conclusion 

The work in this paper was particularly important towards verifying our ap¬ 
proach and learning more about the actual functionality of the algorithm. In¬ 
teractive theorem provers like Coq provide the necessary support to define the 
notions and assertions while being able to effectively prove theorems in a far more 
convenient and reassuring way, in contrast to hand-written, informal proofs, es¬ 
pecially when it comes down to tracking formulas containing alternating quanti¬ 
fiers. Furthermore, the procedure of proving the theorems in an interactive way 
with a tool allowed us to refine our definitions. Additionally, the time that was 
required was minimal when compared to the process of considering the informal 


proofs and writing down our requirements in English. The most important out¬ 
come was the proof of correctness of our approach that enabled us to provide a 
complementary set of definitions and proofs, easily processed by an experienced 
Coq user. 

To conclude, there is substantial additional work that could be performed 
in terms of fleshing out the formalisms used in the proofs for our particular 
implementation. For example, we could define the structure and types of inputs 
and outputs, and describe how transition systems are realized in the AGREE 
tool suite. However, the work that has been performed shows the soundness 
of the proof system and our algorithms with respect to proofs of realizability, 
allowing us to proceed with very high confidence as to the correctness of our 
approach. 
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